home *** CD-ROM | disk | FTP | other *** search
- Path: dawn.mmm.com!news
- From: kjhopps@mmm.com (Kevin J Hopps)
- Newsgroups: comp.lang.c++
- Subject: Re: Placement new = reconstruction?
- Date: 4 Mar 1996 15:25:07 GMT
- Organization: 3M - St. Paul, MN 55144-1000 US
- Message-ID: <4hf20j$69q@dawn.mmm.com>
- References: <4h4hn5$k8c@clarknet.clark.net>
- Reply-To: kjhopps@mmm.com
- X-Newsreader: TIN [version 1.2 PL2]
-
- Harlan Messinger (gusty@clark.net) wrote:
- > Do I understand correctly that placement new allows for reinitialization
- > of an object in place, thereby giving two advantages:
-
- > -- elimination of time spent repeatedly allocating and
- > deallocating, and
-
- > -- elimination of concern over proper destruction?
-
- > In other words, if I have a class Bar that itself performs no allocation,
- > and I need to perform an operation on a series of Bar objects, instead of
- > allocating a new Bar object for each iteration, can I do the following? Is
- > there any reason I shouldn't?
-
- _IF_ Bar performs no "allocation," and
- _IF_ Bar contains no members with destructors, and
- _IF_ you are sure that Bar will never be changed to perform allocation, and
- _IF_ you are sure that Bar will never be changed to contain members with
- destructors, then you are probably safe to construct a Bar repeatedly without
- destroying it between constructions.
-
- I put "allocation" in quotes because it is not only calls to new that you
- need to be aware of. It is any resource allocation or any change in the
- program state which will accumulate with multiple constructions of a Bar.
- This would include things such as opening files or even incrementing a
- static counter.
-
- > Finally, is "placement delete" (i.e., a direct call to bar_->~Bar())
- > required before each placement new, or before bar_ goes out of scope, or
- > is it optional if Bar doesn't dynamically allocate anything and therefore
- > doesn't need to DEallocate anything?
-
- It is optional even if Bar does allocate things. There are no C++ police
- to give you a ticket for not calling a destructor. :-)
-
- > class Bar
- > {
- > public:
- > Bar(const char *stringArg = NULL);
- > ~Bar() {}
- > void doit();
- > };
-
- > Bar::Bar(const char *stringArg) { /* whatever */ }
- > void Bar::doit() { / * whatever */ }
-
- > class Foo
- > {
- > private:
- > Bar bar_; // So bar_ will be destroyed automatically
- > // when Foo is.
- > public:
- > Foo() {}
- > ~Foo() {}
- > void run(const char *stringArg = NULL);
- > };
-
- > void Foo::run(const char *stringArg)
- > {
- > new &bar_ Bar(stringArg);
- > // Instead of deallocating and reallocating,
- > // just create the new version of bar_ in place.
- > bar_.doit();
- > return;
- > }
-
- You seem to going to extremes (and making many assumptions about the Bar
- class) to avoid calling ~Bar(). Why?
-
- In your example, the destructor is inline, and does nothing. The compiler
- should optimize away any calls to it. Further, if Foo::run is the only
- place you use the Bar, why not make it local to that function instead of
- making it a member of Foo?
- --
- Kevin J. Hopps e-mail: kjhopps@mmm.com
- 3M Company phone: (612) 737-4643
- 3M Center, Bldg. 235-2D-57 fax: (612) 737-2700
- St. Paul, MN 55144-1000 Opinions are my own. I don't speak for 3M.
- But 3M speaks for me -- I did not write the following line:
-
- Opinions expressed herein are my own and may not represent those of 3M.
-